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ABSTRACT 


The pharmaceutical industry has evolved from merely Rs.1500 crores in 1980 
to more than Rs. 1,19,000 crores by 2012. Medicines in almost every 
therapeutic category are sold primarily as branded drugs, at 
disproportionately very high prices.80% of out-patient care and 60% of all in- 
hospital care occurs at private facilities in India and majority of households are 
exposed to a private-sector market to buy drugs. According to NSO estimates, 
up to 79% of health care expenses in rural areas are due to the cost of 
medicines. Thus, access to low-priced generic drugs is very critical in ensuring 
health care at affordable prices. 

'Ensuring the availability of quality medicines at affordable prices to all' has 
been the key objective of the Department of Pharmaceuticals, Government of 
India. Hence, it has launched 'Jan Aushadi' as a direct market intervention 
strategy where the high-quality generic medicines would be sold at low prices. 
Such medicines would be equivalent in potency and efficacy to expensive 
branded drugs. This project primarily directs towards providing online web 
facility to ah its customers under Jan Aushadi Scheme for efficient distribution 
of generic medicines under prescription throughout the country mainly 
focusing on rural areas where citizens are deprived of basic knowledge about 
the consumption of proper drugs and their compositions. Through this project, 
we are aiming at providing medicines with respective compositions as per the 
Jan Aushadhi Scheme and ensuring that they get easy access to Jan Aushadi 
drugs using these online services. 
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1. INTRODUCTION 

The pharmaceutical industry has evolved from merely 
Rs.1500 crores in 1980 to more than Rs.1,19,000 crores by 
2012. Medicines in almost every therapeutic category are 
sold primarily as branded drugs, at disproportionately very 
high prices.80% of out-patient care and 60% of ah in- 
hospital care occurs at private facilities in India and majority 
of households are exposed to a private-sector market to buy 
drugs. 

'Ensuring the availability of quality medicines at affordable 
prices to all' has been the key objective of the Department of 
Pharmaceuticals, Government of India. Hence, it has 
launched 'Jan Aushadhi' as a direct market intervention 
strategy where the high quality generic medicines would be 
sold at low prices. Such medicines would be equivalent in 
potency and efficacy to expensive branded drugs. 

This project primarily directs towards providing online web 
facility to ah its customers under Jan Aushadhi Scheme for 
efficient distribution of generic medicines under 
prescription throughout the country mainly focusing on 
rural areas where citizens are deprived of basic knowledge 
about the consumption of proper drugs and their 
compositions. 

Through Jan Aushadhi system can be managed by 
categorising the activities performed by the client, admin 
and the salesman with a simple and user friendly 


application. Medicines of ah genres are accepted and 
dispatched easily with the ease of this application. 

It is a well-known fact that branded medicines are sold at 
significantly higher prices in India. Given the widespread 
poverty across the country, making available reasonably 
priced quality medicines in the market would benefit 
everyone especially the poor and the disadvantaged. This 
has always been a major concern and this is achieved by a 
novel project ''Jan Aushadhi" launched by Government of 
India in the year 2008 for the noble cause-Quality Medicines 
at Affordable Prices for Ah. The campaign was undertaken 
through the sale of generic medicines through exclusive 
outlets namely ''Jan Aushadhi Kendra" in various districts of 
the country. 

This project can be widely used by ah citizens of India and 
shall be accessible at their fingertips using an internet 
connection. It also persuades government doctors to 
prescribe generic drugs with proactive help from State 
Governments. 

1.1 EXISTING SYSTEM 

Here a form is given to the patient in which he/she has to fill 
their details such as name, city, contact details, prescription 
etc. Here the record of transactions of the patient, salesman 
and the admin is maintained in record books rather than in 
an equipped database server. 
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1.1.1 PROBLEM STATEMENT 

> Time-consuming. 

> Chances of obtaining inaccurate information. 

> Doubled efforts in seeking proper help and assistance to 
approach med stores. 

> Leads to lack of knowledge in the intake of drugs. 

> Causes travel expenses. 

> May lead to out of stock conditions. 

> Many times patient is prone to take the wrong dosage 
and composition of medication without adequate 
information during the period of buying the drug. 

1.2 PROPOSED SYSTEM 

Jan Aushadhi management system is a web-based 
management system that is developed for patients under 
this scheme to manage their medicine orders in an 
automated manner. 

First on the website its necessary to make sure that only 
admin is able to change the system's data. So in this system, 
admin id and password is used and without the knowledge 
of admin id and password, none can enter into the system's 
data. Therefore the data is totally secure here and it's not 
possible for any patient or salesman to manipulate data like 
insertion, deletion, modification, and updating of record. 
Authentication is provided to every actor involved in the 
system and any unauthorized user does not get access to any 
extra information from the admin site. 

1.3 HARDWARE REQUIREMENTS 

> Processor - i3 or i5 

> RAM - 2GB 

> Hard Disc - 80GB 

1.4 SOFTWARE REQUIREMENTS 

> Programming Language: C#,.NET 

> Storage: SQL Server Management Studio 2014 

> Front end language: C# 

> Operating System: Windows 7 and above 

1.5 FUNCTIONAL REQUIREMENTS 

A functional requirement document defines the functionality 
of a system or one of its subsystems. It also depends upon 
the type of software, expected users and the type of system 
where the software is used. Functional user requirements 
may be high-level statements of what the system should do 
but functional system requirements should also describe 
clearly about the system services in detail. 

> ADMIN: Authentication to be done while admin enters 
into the portal and website asks for the admin id and 
password for authentication purpose. 

The administrator is responsible for every update and 
addition of information about medicines, salesman etc. 

> CLERK: The customer or the patient under the 
Janaushadhi scheme can be managed with the help of 
this module. 

The entry of the new patient with their detail profile and 
contact information can be done through this module, 
and information will be stored in the database for 
further use and avoid duplication. 

> SUPPLIER: The supplier here functions as a delivery 
man for the dispatch of medicines to respective 
customers. 


He/she will be allocated with a respective patient id to 
who he must deliver the respective medicines. 

> CUSTOMER REGISTRATION: The customers who 
mostly wish to enter their prescription for the delivery 
of medicine need to register thro clerk who enters the 
name, address, mobile number, email id and so on. 

A prescription through registration online becomes 
reliable, as it is easy to maintain the record in an 
organized way where there is no loss of data. 

Mobile no of the customer is taken for authentication 
purpose. 

Admin needs to check the customer's registration and 
update the details in the database. 

Patients can view their previous orders as well. 

> SALESMAN REGISTRATION: The salesman who is 
involved in delivering the medicine package need to 
register for the first time using the name, address, 
mobile number, and so on. 

A salesman can also send a conformational mail while 
the item is being shipped to the customer's email-id. 

Admin needs to keep in control of their orders and 
regularly check new salesman registrations. 

1.6 NON-FUNCTIONAL REQUIREMENTS 

Non-functional requirements are constraints that must be 
adhered to during development. They limit what resources 
can be used and set bounds on aspects of the software's 
quality. 

> Usability: The application which we are developing is 
going to be used by the customer or the stakeholders. 
This is going to help them in predicting the order of 
processing books. 

> Efficiency: Our application takes less time to 
accomplish a particular task such as placing orders 
which also reduces time complexity. It reduces the 
complications when information has several 
functionalities thus increases the efficiency. 

> Reliability: The application that we are designing is 
designed to deliver a set of services as expected by the 
users. The application provides many modules and 
each module is developed to satisfy the non-functional 
requirements by the customer. 

> Maintainability: The application that we are 
developing is going to provide a high-performance 
measures, for example, the data updates are done 
automatically without loss of data that already exists. 

2. SYSTEM DESIGN 

The most creative and challenging phase of system 
development is System Design. It provides the 
understanding and procedural details necessary for 
implementing the system recommended in the feasibility 
study. Design goes through the logical and physical stages of 
development. In designing a new system, the system analyst 
must have a clear understanding of the obj ectives, which the 
design is aiming to fulfill. The first step is to determine how 
the input is to be produced and in what format. Second, input 
data and master files have to be designed to meet the 
requirements of the proposed output. The operational 
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phases are handled through program construction and 
testing. 

2.1 DATA FLOW DIAGRAM 

A data flow diagram (DFD) is a diagram that describes the 
flow of data and the processes that change data throughout 
the system. It's a structured analysis and design tool that can 
be used for flowcharting in place of or in association with 
information. 


2.1.1 DATA FLOW DIAGRAM FOR SUPPLIER 

Here, the supplier can register himself newly or may directly 
login to the portal and view his orders issued by the admin 
and correspondingly deliver them to the customer or the 
patient who has placed the order along with the prescription 
and the quantity. 


X 
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2.1.2 DATA FLOW DIAGRAM FOR CLERK 

Here, the clerk first login to the portal and with his help the 
customer or patient can register himself with his personal 
details if he is a new user or can directly login and enter his 
prescription and also view his details. 



2.1.3 DATA FLOW DIAGRAM FOR ADMIN 

Here, the admin is already registered and first login to the 
portal to perform respective operations. Admin can add 
clerk and supplier and therefore delegate the task 
respectively. Any manipulation in the record is in the hands 
of the admin only 



2.1.4 ENTITY RELATIONSHIP DIAGRAMS 

Entity Relationship Diagrams (ERD) illustrates the logical structure of databases. 
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2.2 TABLE DESCRIPTION 
TABLES 

H JA^USHADJWFQ_SYSTEM 
J Database Diagrams 
jji Table-s 

• i- i jJ System Ta b I« 

+ ■ J FileTables 
t _ J dbo.ailmin 
■ j dbc.bkllln-g 
Lm Z3 d bo.clerk 
ml _□ dbo.eLkBtq-mefl 
*i _J dbo-meetkine 

_□ db?,DldcutlOfnffl 
'*■ _□ dbp.pr^ers- 

■H _□ dbs>--?Mppher 

ADMIN 

J dbc.admin 
■ J Columns 

f id jPK int <wt nulD 
J unmamc (uvchaifSO), 
j paswwdiufchiA 

CUSTOMER 

1=3 3 dbo.derk 
j ZM Cclufflni 

f id t'PK oulri 

3 namr net hull? 

3 netrtullj 

3 -sg* net jVufll^ 

J esriid (vflrchai(3St net nuH] 

13 phone <v*rcbnrt£ft ngt null) 

3 *44nm |yfreh?rJ3G), ng( null I 

3 UTrm?me (virqlii^lOJ, npt n.L-ll' 

3 pw^Dr^fvflrchirtWl. ng( ngIFj 

CLERK 

i- AanCUftomarl 

L-: Column,* 

^ id |£ PK, int. npl nutl) 

nam* (char^O), n^t nviil) 

in ge-nder fcharClOK not nt|llj 

J3 ngc (mt, not null) 

71 phant {V4rc har(3G) r not n^Jr> 
n doe_nan-ie (thiaitiO). not null) 
i] piescriptipn (^nr^Kdi^^ not rvytl) 
in cl*erk_id iint r not nyll) 

I] uwnime (yarchar(JO), not null) 

-1 pflsjwflrd (v«rchqr(fO) r not null) 
fl quantity nuili 

I] email (y«rthAr(jOI nyllj 

MEDICINE 

13 dbo.n-i«fi-chne 

.-1 J CfliliJirsn? 

id £PK. int*. null) 

S3 rufi m cr f e h n.r £ JO) neal null] 

~T1 Type (chottZO). m-li E iiullgi 

eempatty r l h-n r £20] net null} 

~~1 m>an_€iare not null) 

~1 t^p_rJate (date, not null) 

'.’3 price (flc#L not null) 
zn tw-p 'it -Ciri!; i-inJlj 

S3 cli--rfc icd (in-*, n-nt iiiiU'i 
! . I E|ujinlF[y (inT. null]) 
t i —M Ktyi 
k- _j Con*i.r4int-i 
1=1 _^Jk IriHgqt** 

IZI cuibill 


ORDERS 

—1 dbo.^rdcri 
i-l , ii Columns 

f rid (PK. ifil. rlCil rlkjllj 

~1 type (varchartZO), not null) 

n ril-e-m fchari(20]L n£>t null 1 ] 

_U C fc fr ^ n ijl(3 

.3 del_djrte- ('diite. not null) 

_] qui+ntiity tint, not nuPIJ 
_3 ndt f^lpU) 

i*1 sup_id Cin-t not null) 

3 d^E add (yar(har(S0] r inull) 
if cusjCf <FK, tn-t* nolO 
f medjd (Fit ini, nulF) 

3 tdfAI nMlI) 

SUPPLIER 

liii ^3 dbo-.cdstome.r1 
O l Jl CQlumns 

f id (PK int, not nySi) 

_") ndrrte , fchiir(2,0) ii nfit null) 
l 3 grnder (chaffl'D), not nvjll) 

LD eg* (int, root null) 

m phone (varchar(2Q) H not nu.ll) 

l 3 doc_name (cher(203. not null) 

3 prescription fvarchflr(30X null) 

EH ^lerkjcd Crnt, not null) 

_3 utfernome (vdrChOr(2:0), not ri-uM) 

;_3 password (v^rehar^SO), npt null] 

3 quantity (int, null) 

3 email (verchar(3!D). null) 

OLD CUSTOMER 

3 J dbaoldcustomerl 
0 □ Columns 

f id (FIC int, not null) 
j doc.name [char® not null) 
j prescription (varchaftfO], not null) 

J quantity (int, null) 

This portal mainly consists of 8 tables: 

> Admin uses username and password where he logs in 
and performs addition, deletion, updating operation on 
table data. 

> Clerk by entering the personal details and logins into the 
system to perform customer transaction operations. 

> Customer newly registers himself by providing personal 
details stored with respect to the semantics of this table. 

> Supplier table consists of all the personal details of the 
supplier supplying the medicine package. 

> The old customer table is composed directly of the 
prescription provided which does not require any 
personal registration details. 

> Medicine table comprises of all the details regarding 
prescribed medicine and through which clerk order is 
placed. 

> Order table consists of all details regarding orders 
placed like the patient id, salesman id, clerk and also any 
update or deletion and addition is allowed to the admin 
on this table. 
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2.3 FLOW CHART 



3. DATABASE TECHNIQUES AND RESULTS 

3.1 TRIGGER 

A trigger is a special kind of a stored procedure that executes 
in response to certain action on the table like insertion, 
deletion or updating of data. It is a database object which is 
bound to a table and is executed automatically. You can't 
explicitly invoke triggers. The only way to do this is by 


performing the required action on the table that they are 
assigned to. 

3.1.1 TRIGGER CODE 

ALTER TRIGGER [dtra].[cusbill] on [dboj [medicine] 

ArTEft INSERT 

AS 

BEGIN 

declare $id int; 
declare ginaire cha r 
declare Stype char ,2e ■ 
declare gcappany Vfarcha-20 
declare ice flcatj 
declare Quantity int; 

select Aid madlist.id from Inserted aedlist; 
select |name wdlist name frc^ inserted medlist 
select |type ®edlist type frra- inserted medlist 

select gcmpany s^cfllst.-conpariy from inserted medlist 
select |price medlist price from inserted aedlist 
select ^quantity medlist,quantity frtir inserted medlist; 

IftSERT IliTO billing id name, type company .price quantity 
WUJE S |id §nam , gtype ^company r gpr it a. gquarttity 

END 

3.1.2 STORED PROCEDURE CODE: 

CREATE PROCEDURE view.med 
AS 

BEGIN 

SETNOCOUNTON; 

SELECT*from medicine 
END 


4. TESTING 

The purpose of testing is to discover errors. It's the process of trying to discover every conceivable fault or weakness in a work 
product. It provides a way to check the functionality of components, sub-assemblies, assemblies and/or a finished product. It's 
the process of exercising the software with the intent of ensuring that the software system meets its requirements and user 
expectations and doesn't fail in an unacceptable manner. There are various types of test. Each test type addresses a specific 
testing requirement 
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5. SNAP SHOTS 



Fig 5.1 Home page 



fig 5.2 Login Page 



Fig 5.3 Admin Login Page 



Fig 5.4 Admin Option page 



Fig 5.5 Add option page 



Fig 5.6 Delete option page 



Fig 5.8 View option page 



Fig 5.9 Order page 



Fig 5.10 View customer page 
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Fig 5.11 Clerk login 



Fig 5.12 Customer 



Fig 5.14 Supplier view page 



Fig 5.15 Customer login page 



Fig 5.16 Customer registration page 



Fig 5.17 Supplier login Page 


CONCLUSIONS 

The various roles which can be assigned are admin, clerk, 
and salesman. Financial transactions can be made securely 
and integrated into the existing accounting software. Rural 
villagers can also access the portals safely and order 
medicines for door delivery. Transactions are extremely safe 
since only one hand (admin) is involved in the manipulation 
of any record of customer or patient. Any supplier can 
register himself to voluntarily work in delivering packages 
and also has easy access to his orders through this portal. 
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